Existing customer relationship management (CRM) systems may be ill-equipped to model and automate front office business processes because they are primarily designed to capture and manage customer related task data, not perform workflow modeling. Front office processes may require cross-platform functionality that CRM systems cannot handle. Lead assignment and routing, for example, involves customer information requests that originate in a CRM system, but require additional functionality to route the lead information to the appropriate office and sales team. Existing systems rely on integration applications to enable cross-platform function building.
The problem with using integration applications is that using them is expensive. While integration applications are robust, they are tailored for integration technology (“IT”) specialists who are involved in the detailed bridging of disparate systems. These integration applications provide a full array of tools for creating workflow definitions and implementing user-designed workflow processes. However, these applications may be overkill for simple functional extensions of CRM based tasks. In the example of lead assignment and routing above, using an integration application to create a custom solution would require the expensive time of a skilled IT professional. Moreover, integration applications are suited to handle large system integration problems, specifically vertical integration solutions that connect disparate and complex systems along a supply chain. Often times, all that is needed in a CRM application is a simple fix that is within the ability of an average business process developer to define, and which is based on extending the functionality of CRM based tasks.
Some CRM workflow systems, such as Microsoft CRM, provide ancillary workflow tools that include some customization capabilities. However, the functionality is usually limited to what is included out-the-box and is not extensible. This severely limits a business developer's ability to implement a custom solution. Furthermore, to enable an average business developer to implement extensions, a framework must be devised that provides a library of functions, and the functions should be exposed to the user in a business friendly manner. As noted above, design time components are limiting and, thus, the framework should also allow third party independent service providers (“ISV”) the ability to offer components for extending CRM functions. Unfortunately, ISVs are currently not incentivized to provide these components because existing CRM systems require components to implement or inherit CRM object types, which makes the components harder to design and system specific, i.e., inextensible. Moreover, the industry trend is to simply involve IT technicians in producing a solution, even though small businesses do not require a full scale integration effort.
Therefore, there is a need to develop an extensible framework that 1) enables an average business developer to assemble extensions for CRM application functions; 2) enables a CRM system to use a library of components external to its application platform and 3) incentivizes ISVs to develop extension components.